Machine-to-machine (M2M) technologies allow devices to communicate more directly with each other using wired and wireless communications systems. M2M technologies enable further realization of the Internet of Things (IoT), a system of uniquely identifiable objects and virtual representations of such objects that communicate with each other over a network, such as the Internet. IoT may facilitate communication with even mundane everyday objects, such as products in a grocery store or appliances in a home, and thereby reduce costs and waste by improving knowledge of such objects. For example, stores may maintain very precise inventory data by being able to communicate with, or obtain data from, objects that may be in inventory or may have been sold.
Both the 3rd Generation Partnership Project (3GPP) and the European Telecommunications Standards Institute (ETSI), which is one of the standards bodies that is part of 3GPP, have defined architectures to support M2M communications. Specifically, 3GPP has defined an architecture for Machine Type Communication (MTC) in its TS 23.682. ETSI defines its ETSI M2M architecture in its TS 102 690.
Generally, in both architectures, an M2M entity (e.g., an M2M functional entity such as device, gateway, server/platform that may be implemented by hardware or a combination of hardware and software) may provide an application or service. For example, a light sensor may provide data indicating detected light levels or a thermostat may provide temperature data and the ability to adjust air conditioning controls. This data may be made available as a “resource” that may be accessed by other M2M entities and that essentially serves as a means to exchange data between M2M entities. A resource may be a uniquely addressable representation of data that may be addressed using a Universal Resource Indicator (URI). The availability of such resources may be communicated among M2M entities via an M2M service capabilities layer (SCL).
The M2M SCL is a functional entity that may be implemented by hardware or a combination of hardware and software and provides functions exposed on reference points (i.e., functional interfaces between M2M entities). For example, the M2M SCL may provide common (service) functionalities that are shared or commonly used by different M2M applications and/or services. These common functionalities may be exposed using a set of open interfaces. Additionally, M2M service capabilities may use cellular core network functionalities through a set of exposed interfaces (e.g., existing interfaces specified by 3GPP, 3GPP2, ETSI TISPAN, etc.) and may also interface to one or more other core networks.
FIG. 1 is a diagram illustrating the architecture for MTC defined in 3GPP TS 23.682. In this architecture, services capability server (SCS) 112 (also sometimes referred to as an M2M server) is an entity that offers services to MTC applications. As described in TS 23.682, to support both an indirect and a hybrid model of MTC, one or more instances of an MTC InterWorking Function (MTC-IWF) reside in the home public land mobile network (HPLMN) above line 118. An MTC-IWF may be a standalone entity or a functional entity of another network element. The MTC-IWF hides the internal public land mobile network (PLMN) topology and relays or translates signaling protocols used over the Tsp reference point to invoke specific functionality in the PLMN.
As shown in FIG. 1, MTC-IWF 116 resides in the 3GPP core network (CN), and it is able to communicate with a User Equipment (UE)—which may be any type of computing device, such as a mobile phone, sensor, actuator or any other type of M2M device—over several interfaces that are part of the “control plane” of the architecture, such as the T4 and T5 reference points defined by 3GPP. As further shown, SCS 112 communicates with the MTC-IWF via a “Tsp” interface defined by 3GPP. A UE normally communicates with an SCS via the “user plane” of the network. The control plane may be generally described as the communication path that primarily carries signaling traffic over a network. The user plane (sometimes known as the data plane, forwarding plane, carrier plane, or bearer plane) is the communication path that carries user traffic, such as voice communications and data communications (e.g., e-mails or web information from the Internet). In cellular communications, examples of control plane messaging are a page, short message service message, a location area update, an attach, detach, etc.
FIG. 2 is a diagram illustrating a system 120 in accordance with the ETSI M2M architecture defined by ETSI in its TS 102 690. Note that this diagram is simplified to facilitate description of the subject matter disclosed herein. As shown in FIG. 2, the system 120 may comprise a plurality of network domains, such as network domain 122, network domain 130, network domain 135, and network domain 138. Each network domain may include a network service capability layer (NSCL), such as NSCL 126, NSCL 131, NSCL 136, and NSCL 139. Each NSCL may interface with a respective network application, such as network application 127 and network application 132 in network domain 122 and network domain 130, respectively.
As further shown, a network domain, such as network domain 122, may further comprise one or more devices, such as device 145, and one or more gateways, such as gateway 140. In 3GPP parlance, devices and gateways are examples of UEs. As shown, the device 145 may be running a device SCL (DSCL) 146 which communicates with the NSCL 126 over the mId interface defined by the architecture. A device application (DA) 147 may also be running on the device 145, and it may communicate with the DSCL 146 over a dIa interface. Similarly, the gateway 140 may implement a gateway SCL (GSCL) 141 that communicates with the NSCL 126 over the mId interface. A gateway application (GA) 142 running on the gateway 140 may communicate with the GSCL 141 via the dIa interface. In general, dIa reference points allow device and gateway applications to communicate with their respective local service capabilities (i.e., service capabilities available at a DSCL or a GSCL, respectively). The mId reference point allows an M2M SCL residing in an M2M Device (e.g., DSCL 146) or an M2M Gateway (e.g., GSCL 141) to communicate with the M2M service capabilities in the network domain (e.g., NSCL 126) and vice versa.
Still referring to FIG. 2, in greater detail, NSCL 126 may be in domain 122 and configured with network application (NA) 127 on an M2M server platform 125. NA 127 and NSCL 126 may communicate via reference point mIa 128. The mIa reference points may allow an NA to access the M2M service capabilities available from an NSCL in an M2M domain.
Typically, the device 145, gateway 140, and M2M server platform 125 comprise computing devices, such as the devices illustrated in Figures FIG. 7C and FIG. 7D and described below. The NSCL, DSCL, GSCL, NA, GA, and DA entities typically are logical entities that are implemented in the form of software, executing on the underlying device or platform, to perform their respective functions in the system 120.
As further shown in FIG. 2, NSCL 131 may be in domain 130 with NA 132. NA 132 and NSCL 131 may communicate via mIa reference point 133. There could also be an NSCL 136 in network domain 135, and NSCL 139 in network domain 138 mIm reference point 123 may be an inter-domain reference point that allows M2M network nodes in different network domains, such as NSCL 126 in network domain 122, NSCL 131 in network domain 130, NSCL 136 in network domain 135, or NSCL 139 in network domain 138, to communicate with one another. For simplicity herein, the term “M2M server” may be used to indicate a service capability server (SCS), NSCL, application server, NA, or an MTC server. In addition, the term user equipment (UE), as discussed herein, may apply to a GA, GSCL, DA, or DSCL. A UE, as discussed herein, may be considered a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor or actuator, consumer electronics, medical devices, automobiles, and the like. A machine-to-machine services capabilities layer entity as discussed herein may include an M2M server or a UE.
While the 3GPP and ETSI M2M architectures are described by way of background herein and may be used to illustrate various embodiments described hereinafter, it is understood that implementations of the embodiments described hereinafter may vary while remaining within the scope of the present disclosure. One skilled in the art will also recognize that the disclosed embodiments are not limited to implementations using the 3GPP or ETSI M2M architectures discussed above, but rather may be implemented in other architectures and systems, such as oneM2M, MQTT, and other M2M systems and architectures.
One function that can be performed in an M2M network, such as in the 3GPP and ETSI M2M network architectures discussed above, is known as a device trigger. A device trigger is a message that is initiated by a network entity, such as an application server, and sent to a device, usually over the control plane of the network. Because the device trigger is sent over the control plane, an IP address is not needed to address the device. Instead, the trigger may be addressed to an external 3GPP identifier of the device, such as a Mobile Station International Subscriber Directory Number (MSISDN) or a Uniform Resource Identifier (URI). Device triggers can server several purposes. For example, device triggers can be used to send small amounts of application or service layer data from an SCS (M2M server) to a UE (M2M device or gateway). Additionally, device triggers can be used to instruct a DA, GA, DSCL or GSCL on a UE to initiate communications with an SCS (M2M server).
In the 3GPP architecture illustrated in FIG. 1, the MTC-IWF can be used to trigger a UE via control plane interfaces, such as T4 and T5. The MTC-IWF will receive trigger requests from an SCS via the Tsp interface and will perform a mapping between the external identifier of the UE and an internal identifier, such as IMSI. The MTC-IWF will report to the SCS the success or failure of a trigger delivery.
Described herein are several techniques that address limitations of existing M2M network architectures in the area of device triggering.